forked from shaka-project/shaka-packager
-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
update from origin #8
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This brings our default build config more in line with what is necessary for some platforms anyway: using the system-installed toolchain and sysroot to build everything. We will no longer fetch source or binaries for any specific build tools, such as libc++, clang, gold, binutils, or valgrind. The main part of this change is the changing of default gyp settings in gyp_packager.py. For this, a bug in gyp_packager.py had to be fixed, in which similar GYP_DEFINE key names (such as clang and host_clang) would conflict, causing some defaults not to be installed properly. In order to enable clang=0 by default, some changes had to be made in common.gypi: - compiler macros added to fix a compatibility issue between Chromium's base/mac/ folder and the actual OSX SDK - replaced clang_warning_flags variables with standard cflags settings, plus xcode_settings for OSX - turned off warnings-as-errors for non-shaka code, rather than allow-listing specific warning types, since we can't actually fix those warnings on any platform - disabled two specific warnings in shaka code, both of which are caused by headers from our non-shaka dependencies Also, one warning (missing "override" keyword) has been fixed in vod_media_info_dump_muxer_listener.h. Although these changes were done to make building simpler on a wider array of platforms (arm64, for example), it seems to make the build a bit faster, too. For me, at least, on my main Linux workstation: - "gclient sync" now runs 20-30% faster - "ninja -C out/Release" now runs 5-13% faster The following environment variables are no longer required: - DEPOT_TOOLS_WIN_TOOLCHAIN - MACOSX_DEPLOYMENT_TARGET Documentation, Dockerfiles, and GitHub Actions workflows have been updated to reflect this. The following GYP_DEFINES are no longer required for anyone: - clang=0 - host_clang=0 - clang_xcode=1 - use_allocator=none - use_experimental_allocator_shim=0 Documentation, Dockerfiles, and GitHub Actions workflows have been updated to reflect this. The following repos are no longer dependencies in gclient: - binutils - clang - gold - libc++ - libc++abi - valgrind The following gclient hooks have been removed: - clang - mac_toolchain - sysroot Change-Id: Ie94ccbeec722ab73c291cb7df897d20761a09a70
This fixes the Debug build of libpng on arm64 by avoiding CPU-specific optimizations that are not in our sources list. The Release build appears to have been unaffected, possibly due to link-time optimizations or dead code stripping. Change-Id: I900e00fe30b9f3748f2587cfea89a636b3a19811
This converts all time parameters to signed, finishing a cleanup that was started in 2018 in b4256bf. This changes the type of: - timestamps - PTS specifically - timestamp offsets - timescales - durations This excludes: - MP4 box definitions - DTS specifically This is meant to address signed/unsigned conversion issues on arm64 that caused some test cases to fail. Change-Id: Ic752a20cbc6e31fea6bc0894d1771833171e7cbe
There is not a good reason to use a long-lived token attached to shaka-bot. Instead, use a short-lived, automatic token generated by GitHub Actions for the workflow run.
We never produced static release executables on Linux before, but the dynamic libraries they depended on were universal enough that nobody noticed. Now that we have released v2.5 and switched to GitHub Actions for CI builds, the Linux executables depend on libatomic, which is causing issues for some users. Although we can't create fully-static executables on macOS or Windows, we can at least do so on Linux. This adds a GYP variable static_link_binaries which can be set to request full-static binaries on Linux. This also exposes the Chromium build variable disable_fatal_linker_warnings, which is necessary when static linking on Linux due to static-link-related warnings generated by libcurl for its use of getaddrinfo. Finally, this enforces the definition of __UCLIBC__ with static linking on Linux, which is the only way to disable malloc hooks in Chromium base. Those hooks cause linker failures when linking statically on Linux. A new check has been added to the release workflow to ensure that the builds we create are statically linked on Linux. Closes #965
When using CC=clang CXX=clang++, there is a binutils version check that does not work correctly in common.gypi. Since we are stuck with a very old version of chromium/src/build, there is nothing to do but patch it to remove the check. Thankfully, this version number does not control anything critical in the build settings as far as we can tell. Change-Id: Id749d97c5898917592f66136538ee0fa5ca78767
This will also allow us to create official arm64 builds starting with our next release. Change-Id: Iaca5e8406c5e28883346a7884eb0f30815ad0d19
This was causing failures on arm64, where the build action had an arm-specific clause that was skipped due to the missing parameter. Change-Id: I71b7fb15120855c444749dc2216b5f19f0561f6e
The newest pylint release complained about several issues that the older release did not. This resolves those issues: - removes unneeded "u" prefix from strings - adds "encoding" parameter for all open() calls - because "encoding" is a python3-only parameter, use python3 in all the scripts that we control Unfortunately, python2 is required for any scripts that import modules from the ancient Chromium build system we're using (referenced by DEPS), as well as kokoro scripts. Change-Id: I2e9f97af508efe58b5a71de21740e59b1528affd
# LL-DASH Support These changes add support for LL-DASH streaming. **NOTE:** LL-HLS support is still in progress, but it's coming. :) ## Testing `./chunking_unittest --gtest_filter="ChunkingHandlerTest.LowLatencyDash"` `./media_event_unittest --gtest_filter="MpdNotifyMuxerListenerTest.LowLatencyDash"` `./mpd_unittest --gtest_filter="PeriodTest.LowLatencyDashMpdGetXml"` `./mpd_unittest --gtest_filter="SimpleMpdNotifierTest.NotifyAvailabilityTimeOffset"` `./mpd_unittest --gtest_filter="SimpleMpdNotifierTest.NotifySegmentDuration"` `./mpd_unittest --gtest_filter="LowLatencySegmentTest.LowLatencySegmentTemplate"` Note, packager_test must be run from the main project directory `./out/Release/packager_test --gtest_filter="PackagerTest.LowLatencyDashEnabledAndUtcTimingNotSet"` `./out/Release/packager_test --gtest_filter="PackagerTest.LowLatencyDashEnabledAndUtcTimingNotSet"`
The generate_version_string script was only producing correct results in python 2, not python 3. The gyp file that references it explicitly runs it in python3. The shebang line of the script has been updated to match. The script itself has been updated such that it now works correctly in both python2 and python3. Scripts that are only used as modules (not executed directly) have had their shebang lines removed. This fixes CI failures on GitHub Actions. Change-Id: I309bafd2fb05e8fb33f5e092ead179c8c42ea5d3
Now that we have multiple architectures, we should factor both OS and architecture into the names of release binaries. This makes the names more formulaic, as well as consistent with the static-ffmpeg-binaries repository. Shaka Streamer will pull binaries from both this repo and that one, so consistent names would be helpful. The pssh-box release is actually OS and architecture independent, so remove the suffix from that and only release one copy of it. Change-Id: Ief3de49fae267c5267647a8dd4377023777ead37
It was suggested in code review for another project that we update the runner labels for clarity. This brings Packager in line with that, so that we are using the same labels across projects. The runners have already been updated to register with the new label. Change-Id: I30b22530225b5bd22b965ba98d276bcd74ade6cf
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.